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(54) Title: SERVICE PROVISION IN COMMUNICATIONS NETWORKS 
(57) Abstract 

It is desirable in communications networks to be able to offer a variety of services to the customer, and to be able to add or modify 
the portfolio of services available. A service delivery infrastmcture (21) is provided, which would sit in (he Senfice Control Point of 
an intelligent network architecture, and which delivers services using an amy of service independent features (20). In the arraneement 
descnted. the service delivery infrastructure (21) has an object oriented architecture and interacts with systems, such as billing (22) and 
network management (40). m the communications network by means of objects within the infrastructure (21). An aspect of the infrastmcture 
(21) IS the provision of selected sets of services to users of the communications network, which selected sets effectively provide dedicated 
service networks (30) to each customer ^^^ai^u 
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SERVICE PROVISION IN COMMUNICATIONS NETWORKS 

The present invention relates to the provision of services over 
communications networks. If finds particular application in networks where 
5 intelligence, that is decision-making or data processing software, is provided 
elsewhere than in network transmission and switching apparatus, such as in networks 
having an "intelligent network" architecture for instance. 

In communications networks technology, an area which is fast evolving is that 
of providing a choice of services to network users. These services might be voice, 
10 data, video or multimedia-based for example and reply on different network 
capabilities. Increasingly, and more so in the future, services over a single network 
may be provided by several different service providers, and the network provider may 
be a different entity again. That is. the world of communications services, or 
information services, is growing much more flexible but also complex. 

It is desirable, particularly for the network operator but also for service 
providers, that services can be introduced quickly and flexibly, without undue delay or 
cost. Both the network operator and the service provider will need to be able to 
provide those services to customers as fast and as cheaply as can be achieved. 

A development in recent years, in the switched telecommunications 
20 environment, has been the provision of intelligence in communications networks 
which lies elsewhere in the network architecture than in the switches, or exchanges, 
for switching traffic in the network. This allows much improved flexibility in service 
provision, since it is no longer necessary to update all the network switches to instal a 
new service, but still only goes as far as laying a basis for developments in service 
25 provision. The infrastructure needed to deal with not only technical support for a new 
service, such as number translation facilities or transmission bandwidth, but also 
management aspects, such as billing and charging, and order handling, is still a major 
challenge. 
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Figure 1 shows schematically a basic intelligent 
nerwork (IN) model. The transmission network 100 connects 
customer premises equipment (CPE) 105 by means of switches 
110. However, above the transmission network level, there is 
5 the service control level, incorporating Service Control 
Points (SCPs) 115, and above that again comes the service 
management level, incorporating a Service Management System 
(SMS) 120. 

The IN equipment is used to provide services over and 
10 above basic telephony, this being provided by. means of the 
transmission network as of old. The IN type services, such 
as those based on number translation, are provided 
differently. 

Each switch 110 incorporates a Service Switching Point 
15 (SSP). When a call comes into a switch 110 from CPE 105, the 
Service Switching Point is used to pick out calls identified 
as needing Intelligent Network services. It does this by 
reference to trigger tables in the SSP. If the call is an 
IN call, which will usually be identified by the associated 
20 destination number, the SSP in the switch 110 triggers 
intelligent processing by passing a request to an SCP 115. 
The processing of the numbers which do not trigger at the SSP 
in the switch 110 proceed to be routed and carried by the 
transmission network 100 as in the past. 

On receipt of a request, an SCP 115 uses call-related 
information, usually the destination number, to locate 
service logic which it then executes. This service logic 
execution is done in a "Service Logic Execution Environment", 
or SLEE, in the SCP. A Service Data Point (SDP) 125 is used 
JO by the SCP 115 for information it needs in processing. After 
execution of the service logic, the SCP 115 passes control 
back to the switch 110 and the call proceeds, carried by the 
transmission network 100 but now in accordance with the 
executed service logic. 
5 The introduction of the service logic has, to date, 

most usually been to supply number translation and alteration 
of charging mechanisms. Number translation comes into olav 
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when a dialled number is not the actual network destination 
number. For example, a Freephone (0800) number is not an 
actual network destinarion number. It does though trigger 
SCP processing that will translate the dialled number into an 
5 actual number to be called. The service logic in this case 
will also change the charging mechanism in that it reverses 
the normal charging policy, so that the called party will 
receive a bill rather than the calling party. 

A Service Management System 120 is used to manage 
10 trigger tables in the SSP of the switch 110, the installation 
of service logic in the SCP 115, and the management of data 
in the SDP 125. 

This placement of service logic in an SCP 115 
effectively, takes sophistication out of transmission network 
15 switches 110. Since it is not necessary to have nearly as 
many SCPs_ 115 as there are switches 110 in the current 
British Public Switched Telecommunications Network (PSTN) 
100, this has the advantage of greatly decreasing the number 
"of software modules which need to be modified to deploy or 
20 enhance IN services. 

Functionality in an Intelligent Network architecture 
can be provided from various software modules. For instance, 
an Intelligent Peripheral 130 might be used to provide simple 
resources directly to the switch 110, such as security checks 
25 on the use of Personal Identity Numbers. Another development 
has been provision of a Service Node 135, this itself 
incorporating a switch. Service Nodes 135 can provide 
relatively complex resource interactions. 

These functional blocks of equipment, the SCP 115, SMS 
30 120, Service Node 135 and Intelligent Peripheral 130, 
generally comprise computing platform 140 on which sit 
applications 145. The applications 145 are pieces of 
software by means of which the computing platform 140 is 
controlled to provide functions, via an Applications 
35 Programming Interface (API) 150. 

In practice, the service control level will be an 
information network in its own right and can be extremely 
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complex. Each SC? 115 may be connecred to other SCPs 115. 
For instance, if a service is uO be provided over what is 
geographically a wide area, for instance internarionally, it 
is difficult to provide the service by means of only one SCP 
5 115. In such a case, an SCP 115 might be provided in each of 
several regions, for example in each country for an 
international service. The service data then has to be 
distributed to the databases of all these SCPs 115. Rather 
than using the transmission network 100, according to the 
10 intelligent nerwork principle of separating service control 
from the transmission nerwork 100, it will be preferred that 
inrer-exchange (SSP-SSP) signalling should be independent of 
the services and should nor therefore carry IN-based service- 
related information. Consequenrly, SCP-SCP communication 
15 will be needed for transfer of service-related information, 
for example for number translation where the original SCP 115 
has no translation information. 

Funcrionality in an IN architecture can often 
optionally be provided from different places in the 
20 architecture. Looking at the SCP 115 and the service node 
135, the service applications 145 which dictate the services 
which in practice are available to a network user can be 
provided from either system. However, there remains the need 
for services ro be flexible and this has resulted in service 
25 creation facilities 160 taking on considerable significance. 

Known service creation techniques are based on the use 
of standard sets of service logic building blocks which can 
be brought togerher in differenr combinations to provide new 
or different services. These are then made available to 
30 users of the Transmission nerwork 100 usually by being 
compiled at the SC? 115, and managed by means of the Service 
Managemenr System (SMS) 120. 

In particular, a Service Creation Environmenr 160 may 
comprise a set of software tools which can be used ro create 
35 service logic. The logic is then supplied to a Service Logic 
Execution Environmenr (SLEE), to create the functionality for 
instance at the SCP 115 or the Service Node (SN) 135. 
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This type of arrangement: has considerably changed the 
communicarions business, at least in the telephony-based 
area, in than service crearion is available and can be 
carried out hot: only by the software engineer but, in effect, 
5 by rechnically non-expert, for instance marketing, personne-^. 
This is enabled by providing service creation facilities 160 
working at a "user-friendly" graphical user interface level, 
for instance based on icons or simple text statements which 
can be pulled into flow chart representations of service 
10 "mechanisms". The flow charts are however direct 

represenrations of service logic which can then be loaded at 
the SCP 115. 

The above describes the basic principles of service 
creation in known IN environments, wherein new services can 

15 be provided by pulling together standard building blocks from 
a portfolio of building blocks in relevant combinations. 

The technical area of the present invention is 
compiemenrary to this type of service creation but is more 
"concerned with the deployment and delivery of services 

20 created, than with the creation process itself. As can be 
imagined from the above description of IN architectures, the 
complexity of services which can be made available to 
individual users, or to groups of users, is very great. 
There is an obvious need for infrastructure to support and 

25 manage service delivery, which can allow the service provider 
or user to take advantage of the flexibility of the 
developing service creation capabilities without also 
creating insurn:cunT:able difficulties in service management or 
access. 

30 According zo a first aspect of the present invention, 

there is provided a service delivery system, for making 
services available over a communications network, where one 
or more services selected from a group of services is made 
available to at least one network user, wherein said service 

35 delivery system comprises service provision functionality 
dedicated to said at least one user, the functionality so 
dedicated comprising a service directory defining the one or 
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more seiecred services available to thar user, and a number 
direcrory defining a virtual nerwork dedicated to that user 
our of said communi cations nerworic, within which the services 
of the service directory are available to thar user. 
5 By structuring the service provision functionality 

according to dedicated virtual networks carrying dedicated 
service sets for respective users, it becomes relatively 
simple to allow new services to be made available to a user. 

Preferably, the service delivery system is provided 
10 with a stored array of service independent features, 
sometimes referred to as "Generic Service Components" (GSCs), 
and means for accessing rhe service independent features to 
support provision of a service from a service directory, over 
a virtual network within which the service is available, in 
15 response to a call instance relevant to the virtual network. 

Features m this context can be defined as reusable IN 
components used in the construction of a service. For 
instance, "Call Forward" is a feature in which a new 
destination is always generated and is clearly an IN service 
20 feature. However, the nature of the new destination, which 
could be a fax mail-box or another telephone for instance, is 
not determined until thar feature is used in building a 
service. Hence the , feature is independent of the particular 
service it might be applied in. 

'^^^ ^se of a stored array of service independent 
features, accessible ro support services on any of the 
virtual networks, makes it particularly easy to add to and 
enhance the services which can be delivered by the system. 
That is, the stored array can be simply extended or amended 
30 and relevant service directories then updated when 
appropriate to add a service, for instance at user request. 
In this way, only a single set of service features needs to 
be changed, rather than individual sets for each user or 
customer record. 

embodi.Tients of the present invention, a process for 
providing a service by means of a communications network, in 
real time, might comprise receiving an initiating call from 
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a user whj.ch purports to initiare provision of. said service, 
verifying availability of relevant service independent 
features in the context of the initiating call by reference 
to a user profile, and using the service delivery system to 
5 respond to said initiating call in accordance with the 
outcome of said verification. 

Said verification and response can be carried out by 
means of a blackboard technique, said user profile calling on 
service independent features which each will register a view 
10 with the blackboard and, when triggered by that view, will 
process the view, plus any additional parameters, and post 
back resulting scenes on the blackboard so that subsequent 
interactions between features and the -blackboard will be 
affected where appropriate by the preceding interaction. 
^5 Features are "insulated" from the real physical world 

in embodiments of the present invention by working with 
logical representations. Features are assigned to profiles, 
each profile being a data package associated with a network 
"operator, a customer or a user, and features are triggered in 
20 a novel manner by use of the blackboard technique, being 
managed overall by the application of rules. 

The principles of such a service creation and delivery 
environment can allow the network operator a high- degree of 
control and flexibility. Surprisingly, although blackboard 
25 techniques are known in the field of artificial intelligence 
(AI) as being too slow to transfer to complex systems, it has 
been found possible in embodiments of the present invention 
to limit the complexity "visible" to the blackboard process 
in a manner which overcomes the question of speed, in spite 
30 of the potential complexity relevant to any commercially 
competi ti ve communications network. 

It has also been recognised in making the present 
invention that there can be a significant advantage in 
discerning between features and infrastructure in 
35 implementations. By separating features from infrastructure, 
communications networks, and the services available thereby, 
can be built to the customer' s specification by only 
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including features from a feature portfolio that are required 
rather than by inhibiting RCcess to network functionality. 
In previous implementations, the features have in practice 
been so closely related to the basic network services that 
5 feature selection has affected both access to network 
functionality and physical architecture. 

A particular advantage of embodiments of the present 
invention is the independence of features, germane to service 
prevision, from physical network attributes. This means that 
10 service provision becomes decoupled from transmission 
technology and therefore for instance transportable from 
conventional to synchronous digital hierarchy (SDH) - based 
and asynchronous transfer mode (ATM) - based networks, 

A further aspect of embodiments of the present 
15 invention is that of dynamic replaceability, allowing new 
features to be added for any particular user, or to a 
particular network, without the need to interrupt service. 
This is facilitated, according to embodiments of the present 
invention, by a mechanism relying on a Service Delivery 
20 Infrastructure (SDI) which provides the insulation of 
features from the complexities of the physical world 
mentioned above by working with logical representations of 
callers and stations. In particular, an SDI provides virtual 
networks to the user or customer by building in 
25 representations which take the form of Virtual Network 
Directory Numbers (VNDNs). 

An embodiment of the present invention will now be 
described, by way of example only, with reference to the 
accompanying Figures in which: 

Figure 1 shows, as mentioned above, a basic model of 
an intelligent network according to known network 
architectures; 

Figure 2 shows the Service Delivery Infrastructure 
(SDI) in the context of external systems and IN services; 

Figure 3 shows a schematic representation of networks, 
real and logical, supporting the SDI of Figure 2; 
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Figure A shows the contexr of the SDI of Figure 2 
amongst actual systems of a transmission network; 

Figure 5 shows elements of a transmission network as 
viewed by the SDI of Figure 2; 
5 Figure 6 shows a relationship between node addresses 

and network addresses in a physical network of the SDI of 
Figure 2; 

Figure '? shows resource arbitration in a physical 
nerwork of the 5DI of Figure 2; 
10 Figure 5 shows the internal architecture of the SDI of 

Figure 2; 

Figure ? shows a graphical representation of 
scheduling of a directory numbers- 
Figure 10 shows SDI/system interfaces; 
15 Figure 11 shows virtual network access to a service, 

in the SDI of Figure 2; 

Figure 12 shows the limited view a virtual network 
holds of the transmission network, via a Physical Network of 
"the SDI of Figure 2; 
20 Figure 13 shows an SDI context in terms of interfaces, 

internal and ex-ernal to the SDI; 

Figure 1-; shows a message diagram for the SDI of 
Figure 2; 

Figure 15 shows communications between resources using 
25 a "rans action protocol of the SDI of Figure 2; 

Figure 16 shows a dialog composition using the 
transaction protocol; 

Figure 17 shows the components of an inter-resource 
operarion using rhe transaction protocol; 
30 Figure 18 shows the components of a leg in a call 

expressed in the transaction protocol; 

Figure 19 shows the composition of "Physical Network 
Address", a cor.ponent of the leg of Figure 18; 

Figure 20 shows a communication model for a SLEE 
35 supporting an SDI application; 

Figure 21 shows components of a DMSU as a Transport 
Network Resource using the transaction protocol; 
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Figure 22 shows components of a Speech Applications 
Platform as a Transport Network Resource using the 

transacrion protocol; 

Figure 23 shows an event trace for profile retrieval 
5 by a Virtual Network; 

Figure 24 shows physical node discrimination by 
components of the SDI; 

Figure 25 shows a dictionary class interface for use 
in provision of persistent objects; 

Figure 26 shows a process control state transition 
diagram for processes run on a target platform to embody the 
SDI; 

Figure 27 shows a pictorial representation of steps 
carried out by the SDI and related applications in response 
15 to an incoming call, to trigger relevant features; 

Figures 28 to 43 show the compositions of the 
following software entities within the SDI of Figure 2: 

Transaction Protocol; 

Physical Network; 
2 0 Physical Node; 

Physical Node Directory; 

Resource Allocator; 

Virtual Network; 

Profile; 

2 5 Virtual Node Directory; 

Virtual Number Direcrory; 

Virrual Directory Number; 

Virtual Nerwork Address; 

User Direcrory; 
30 Service Dictionary; 

Toll Ticker; 

Network Interconnect; 

Virtual Node; and 

Figures 44 to 48 show schematic flow diagrams for the 
35 following operarions on or using the SDI; 
service crearion; 
virtual nerwork provisioning; 
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physical network/network interconnect provisioning; 
service (instance) provisioning; 
processing an incoming call. 

It might be useful to note in the following 
5 description that "virtual network" is a term used to describe 
a network effectively dedicated to use of a single customer, 
such as an international corporate entity, which appears to 
the user much as a private network would have appeared in the 
past, defined in dedicated hardware, but which is defined 
10 from a greater transmission capability usually simply by 
software. That is, the virtual network is only limited, for 
instance in geographical layout and in capacity, by a 
software specification, in accordance with the recjuirements 
of the customer, which specification allocates resources from 
15 a transmission network. 

For, instance, a network provider may have installed 
international voice and data carrying highways, 
interconnected by switches so that voice and data can be 
routed appropriately, which carry multiplexed traffic for 
20 multiple customers, each customer however only being able to 
access traffic which originates and terminates at their own 
Customer Premises Equipment (CPE). 

In embodiments of the present invention, each customer 
can not only choose to change the physical capacity available 
25 to them by means of a virtual network but can also, 
independently, choose to change the service portfolio 
available to them. For instance, a customer might already 
have available "time-of-day routing", in which incoming calls 
can be automatically rerouted after a particular time such as 
30 close of business away from individuals' offices to a number 
providing a recorded message- They might then decide they 
also need authorisation of outgoing calls to international 
destinations. 

In the foil owing, object oriented software engineering 
35 terminology is used. In object oriented software systems, 
data and functionality are brought closely together in 
representations of real-world entities. The real-world 
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enriry may be an arricle or a process for insrance, an 
organisation or a booking procedure, bur every real -world 
enriry can be represenred in the software system as an 
"object", that is a combination of data relating to the real- 
5 world entity, encapsulated in process -rel ared software for 
accessing thar dara. The software implemenring an object can 
thus be described as data structures together with operations 
that express the behaviour of the object, and the entity 
represented by the object: is any thing, real or abstract, 
10 which one can describe in data plus operations to manipulate 
rhe data. 

SDI Internal Architecture 

Referring to Figure Q, overall the architecrure of the 
15 SDI 200 itself is structured as follows: 

i) an array of virtual networks 800; 

ii) one or more transmission (transport) network 
obj ects 805; 

iii ) a network interconnect object 810; 

20 iv) a library 815 of service independent features (or 

generic service components); 

v) one or more network operator' s management network 
objects 820; and 

vi ) a service engine 825. 

25 This effectively provides the following: 

• virtual Encapsulation of physical transport 
networks ; 

• provision of customised communities of users and IN 
services over these abstracted transport networks - multiple 

30 virtual networks; 

• logical de-coupling of the overlay of Virtual 
Networks onto Transport Networks; 

• provision of libraries of Generic Service 
Components which can be utilised to dynamically create new IN 

35 services; 

• provision of a new interpretive program upon which 
these services execute; 
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• provision of a virtual encapsulation of management 
and supporr sysrems; 

• IN services within a virtual network can be 
provided on one or more transport networks where transport 

r networks can be different telecommunications networks; 

• provision of a commonly owned program interface to 
all components of the framework. 



10 



Transport: Metwnrk Abstraction 805 

The SDI transport network abstraction provides a 
virtual encapsulation in software of the topology of a 
physical network and of the networks elements' capabilities, 
protocols and call models. It manages the resources involved 
in a particular call within that particular network. 

As new elements would appear in the transport network, 
to be utilised by virtual networks or IN services, then new 
encapsulations of those elements would be brought into the 
appropriate transport network abstraction. 

Each network element encapsulation supports the common 
20 3T-owned interface into the SDI. 

Manaaemgnr Network 820 

This component exhibits much the same encapsulation 
principles as the Transport Network but is more specifically 
25 representative of non-call processing entities such as credit 
bureaux, billing systems and other operational support 
systems. it provides virtual encapsulation of each 

particular system interface and protocol and offers a common 
interface into other SDI components. 

30 

Virtual Network 800 

This is the powerful innovative technique of providing 
communities of users as a Virtual Network. The community 
specification is arbitrary and may be a complete 
j5 telecommunications company, a corporate network or a group of 
disparate physical stations from one or more 
telecommuni cations networks . 
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The services available on a particular VN are defined 
within the scope of that VN. They are created using a BT- 
creaced syntax which identifies the componenrs and running 
order of components in the Generic Service Components 
5 Library. 

Users on a VN have specific identities and are 
configured, through service creation tools, to have accBss to 
particular configured instances of one or more of the 
available IN services. 

The instances of the services are deployed and 
configurable using service creation tools accessible from 
numerous interfaces such as human, telephony or operator 
assisted. 

Network Interconnect 8 10 

This provides BT with the highly configurable 
robustness to provide a logical association to determine 
which nodes /stations in the set of available transport 
networks constitute a virtual network. 

'^^^s enables dynamic reconfiguration of the underlying 
physical implementation of virrual network by the virtual 
network provider without the need to change the Virtual 
Network itself. Reasons for such change could be numerous 
examples being network outages, change of network provider, 
25 etc. 

Service Engine 825 

This is an innovative interpretive virtual processor 
upon which services execute. It relies on a "blackboard" 
30 software processing technique with limited feature sets to 
keep processing tines within acceptable limits for real time 
operation. 



GenerzLc Service Componenr Library 8iS 

"^^is IS the library of components created and deployed 
as part of the service creation process that are available to 
be used for IN services. 
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Any IN service within a VH 800 is specified in terms 
of these GSCs. 

Overall, an SDI 200 according to an embodiment of the 
present invention employs a number of innovative abstraction 
5 approaches to the delivery of IN services thar, combined, 
exhibit an adroit capability to provide IN services within 
and across networks for a wide range of applications. 

1. REQUIREMENTS FOR SDI 

10 

Referring to Figure 2, the SDI 200 is required to be 
a real-time, IN element, software environment. It is 
intended that the interfaces with external elements are 
encapsulated and presented to the services 205 in a 

15 consistent logical manner. 

1 - 1 System Architecturg 

Referring to Figures 1 and 2, the SDI 200 resides on 
an Intelligent Network Element (e.g. SCP 115 or SN 135) which' 

20 is within the ambit of a Service Creation Environment (SCE) 
115. The SDI 200 and the applications running under its 
auspices provide the call processing part of an IN service. 

The SDI 200 has transmission network interfaces 1010, 
primarily to the SSP 110, a service creation interface 1000, 

25 operations and management interfaces 1030 and a human/machine 
interface 1020 for a network operator user. 

The SDI 200 supports the establishment of multiple, 
discrete, service-less virtual networks to which services can 
be added. The SDI provides the basic service framework under 

30 which IN services operare, presenting common interfaces to 
management and billing systems. 

Each discrere virtual network 800 of the SDI 200 
should be configurable m terms of the services available on 
it, the users on it and the services available -o each user. 

35 A virtual nerwork can represent any classification of users, 
e. g, a corporate nerwork or a particular subset of the public 
network. 
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The SDI receives ail provisioning information through 
a provisioning interface, for mseance from other systems in 
zhe SCE 210. 

5 1. i. 1 Performance & Di.-nensionina 

A limited number, for instance one hundred and fifty, 
of virtual networks 800 may be defined. The number of users 
m each network may be configured but the total number of 
users for all networks will be limited, for instance to 

10 2,000,000. The SDI software downtime should also be limited, 
:or instance to not more than 2 minutes in any one year. 

For ail services on the networks and services 
supported by the SDI, a reasonable target of calls handled 
per second in the busy hour might be 160 (576,000 BHCA). The 

15 response time to call messages received should be less than 
for instance 100 .-nilliseconds for 98% of all messages at 80% 
loading. Full loading is considered to be the product of the 
average number of messages per call and the maximum number of 
busy hour call attempts. 

20 

1- 1- 2 Software E!nai neeri ng 

The SDI needs to be a real time application. The SDI 
and its interfaces have been developed using Object Oriented 
technology. The development needs to be portable and 
25 implemented by a set of re-usable modules. A suitable target 
platform might be based on Stratus hardware. 

1. 1. 3 Use and Usage Requirements 

The SDI 200 can co-exist on the SCP or SN SLEE. In 
30 the following, it is described as being on the SN SLE£. The 
SDI design endeavours to re-use components of the SN SLEE 
where encapsulation makes engineering sense and offers 
acceptabl e delivery ti.me-scal es. 

SDI software upgrades need to be backward compatible, 
3 5 where the operating systems permit. By designing components 
to be dynamically replaceable, and other appropriate design 
principles, SDI upgrades need cause only short disruption to 
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service, for instance of no more than one minute (where no 
operating system or third party product is involved). It 
should be possible to roll -back out of upgrades to SDI 
components . 

mi 

1. 2 Types of Network 

Referring to Figures 3 and 8, in the following 
description of the present embodiment, there is one physical 
transmission network 100, which carries e. g voice traffic, 

10 upon which logical (virtual) networks 800 are constructed. 
The physical transmission network 100 can be considered to 
comprise all the physical elements that make up the totality 
of the telecommunications network from transmission 
equipment, switches, cross -connect points etc. 

15 Each virtual network 800 of the SDI 200 needs some 

logical means of addressing physical nodes 200 within the 
transmission network 100 to which its users are connected. 
Services are then built on the concept of virtual network 
directory numbers and users, rather than transmission network 

20 directory numbers and users in the transmission network 
context. 

The establishment and management of the transmission 
network 100 is handled in the network operations, planning 
and management domain of the network operator' s business. 

2 5 The provision of virrual network directory numbers is a step 
towards insulating the virtual network from the physical 
network topology. (There is further discussion of this area 
later in this specification. ) 

If the physical nodes 300 are to be addressed, the 

30 physical name of the particular nodes need to be declared to 
the SDI 200. This physical information is localised within 
the SDI 200 as an SDI "Physical (or Transport) Network" 805. 
This is effectively then a projection of a small proportion 
of the transmission network 100, in the SDI 200, supporting 

25 the virtual (or "service") networks 800. Each virtual 
network 800 has associated with it only the nodes 300 in the 
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transmission nenwork 100 required to connect users to that 
nerwork. 

Referring to Figure 3, the SDI Physical Network 805 
also provides a logical representation of network 
5 capabilities. Virtual Networks 800 then logically group SDI 
Physical Network nodes 305 together with services. Virtual 
networks 800 provide services to Customers. Each customer 
has only the top-level view - a dedicated virtual network 800 
of services. 

Based on the above, the following passages are: 

• Section 1.3: "SDI Physical Network" 805 - 

covers the requirements of representing that part of the 
Transmission network that is required to deliver IN services. 

• Section 1. 4: "Virtual Networks" 800 - covers the 
15 requirements of virtual networks 800, their establishment and 

ccnfiguration. This section deals also with services in the 
context of the SDI 200 and how they are added. 

• Section 1.5: "Network^ Interconnection" - addresses 
the linking of the many virtual networks 800 to the 

20 transmission network 100 and determination of the appropriate 
network to handle calls. 

• Section 1. 6 through Section 1. 10 - addresses 
requirements that span all of the application such as time, 
statistics, persistence and control. 

25 

1. 3 SDI Phvcical Nprwork 80*5 

The topology of a physical network 805 is independent 
of a logical virtual network 800 provided over it, provided 
the capabilities of a particular node 300 are promulgated to 
30 a virtual network 300; e.g. a service needs to know if a 
station on a node 300 is capable of accepting a text string 
for caller name delivery. The physical network 305 of the 
SDI 200 is the knowledge of those points to which it 
interfaces in the transmission network 100. 

'^he SDI physical network 805 should isolate and 
uncouple vendor specific detail with respect to the 
transmission network 100 from virtual networks 800 and from 
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each other. The mrsrface presenred to ail virtual networks 
BOO from the physical network 805 should be consistent. 

The SDI physical network 805 can be extended as required. 
5 Referring to Figure 4, nodes of the transmission network 100 
of the current British PSTN which might be identified for 
inclusion in the SDI physical network 805 are the Digital 
Main Switching Units 400 (DMSUs), the SN Switch 405 (through 
the Service Node SLEE interface) and the SSP 110. 

^0 Through suitable encapsulation, knowledge of the 

underlying transmission network 100 is not required by a 
service in order to operate. This allows services to be 
independent of aspects such as signalling protocols, call 
models, modification to the transmission network 100 and the 

15 physical access mechanisms offered by the physical network 
805. A_ service can ascertain some limited physical 

attributes of a station e. g. display capabilities for caller 
name display. 

Physical elements to which the SDI 200 must interface 

20 are represented by objects in the SDI 200. It is possible to 
have any number of instances of an element type, e. g. there 
are a number of instances of SSPs representing the N actual 
SSPs declared to the SDI 200. Encapsulation of physical 
elements (objects) can be created, modified, and deleted as 

25 required to reflect the physical transmission network 100. 

An encapsulation (object) is a reflection of an actual 
physical element in software. This extends to the behaviour 
and state of an element that is required for the SDI 200 to 
inter-operate wizh it. E.g. for an SSP 110 this would 

30 include the call .'nodel, the signalling protocol and the trunk 
configuration. An object is provisioned with the state 
information of the actual element. For an SSP 110, it will 
reflect the SSr-identity and all virtual trunk identities as 
configured by network operations. Each object will be 

35 addressable and state information is provisioned and modified 
through a provisioning interface. 
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Referr^ing zo Figure 5, to the SDI 200 the objects are 
effecrively the actual entitles. By the management of 
conrrol state information, it is possible to take an object 
500, 505 (and, as far as SDI is concerned, the actual entity) 
5 temporarily our of operation and to restore it to operation. 
Newly created objects are out of operation until explicitly 
brought into service. Additions and updates to the SDI 
physical network 805 can be reflected in the SDI 200 by the 
deployment of a new object for the element concerned, 
10 produced by the SCE 210. 

^- 1 Physical Node & Physical Node Addrpcig 
Network elements m the transmission network 100, 
which carry calls, generally carry calls over trunks. The 
15 elements and rheir trunks are addressable and are usually 
connected to other nodes on the transmission network 100. 
Consequently, to the SDI 200 a physical node 300 shall be a 
trunk identity on a particular network element. Nodes of the 
SDI physical networks 805 have the attribute of being 
20 dedicated or common, a "dedicated" physical node being 
understood to be a permanent connection carrying calls for 
a particular virtual network 800. A "common" physical node 
might carry calls for more than one virtual network 800. The 
common or dedicated artribure of a physical node is 
25 changeable. 

Nodes 305 of the SDI physical network 805 have an 
identity by which they are addressed for provisioning. SDI 
physical nodes 305 are provisioned through a provisioning 
Interface. They may be created, deleted or modified for a 
30 particular virtual encapsulation of a physical element. An 
SDI physical node 305 may exhibit a state of enabled or 
disabled, reflecting the condition of a transmission network 
node 30Q. In the disabled state, the SDI 200 will not accept 
or place calls from or to it. 
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4. 3. 1. 1 Physical Node Address 

The physical node 300 that a call originates from or 
is directed to is idenr.fied, for call processing purposes, 
by a physical node address. All physical nodes 300 have a 
5 physical node address. The physical node address and the 
physical node identity are not the same thing. 

For dedicated physical nodes of the SDI physical 
network 805, the physical node address comprises the physical 
element identity and trunk identity. 
^0 Common physical nodes carry calls switched over other 

networks - there is no guarantee that two calls from the same 
station always arrive or leave on the same common physical 
node. Therefore, the physical element identity and trunk 
identity is nor parr of the physical network address for 
15 common physical nodes. For common physical nodes, the 
physical node address comprises, either or both, the calling 
line identity and the dialled number. The physical node 
address for a common physical node may contain anything that 
may be dialled from a Dual Tone Multi Frequency (DTMF) 
20 keypad, including * and #. Table 1 shows the construction of 
the physical node address. 
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/ = Will be present & meaningful: x = will not be present or present and not meaningful. 



30 Table 1: Physical Node Address 



1. 3. 2 Physical Network Address 

A node 305 of the physical network 805 will, 
generally, only identify a group of possible network users. 
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It should be possible to identify and address users uniquely 
on a part:.cular node. A physical network address uniquely 
identifies an access or termination on the physical network 
805. The physical network address comprises a physical node 
5 address and an identifying number. What the identifying 
number may be varies depending on circumstance as shown in 
Table 1. The schematic in Figure 6 shows examples of 
physical node address 600 and related physical network 
address 605. 

10 

1. 3. 3 Operations on the Physical Network 
The composition of the physical network 805 is shown 
in Figure 29. 

As an encapsulation of the real world for virtual 

15 networks and services, the SDI physical network 805 must 
provide a set of operations to allow interaction with 
resources and users connected to the physical network- This 
set of operations on the physical network 805 must satisfy 
the required operations of the service interface. The 

20 operations the physical nex:work 805 must offer are detailed 
in the following paragraphs. 

The physical network 805 manipulates the legs of a 
dialog (call) with respect to the physical elements of the 
transmission network 100 as requested. It offers a standard 

25 set of operations and localizes any specialized knowledge of 
individual transmission network elements. Physical networks 
operations enable legs to be created and deleted. If a leg 
is deleted which is the only leg within a dialog then the 
call is cleared and the dialog is ended. It is possible to 

30 specify an announcemenr to be played immediately prior to the 
deletion of a leg to advise the end user. Legs within a 
dialog can be connected using a connect operation which will 
connecr the specified legs within a dialog together. 

The playing of announcements differs across physical 

35 elements of the transmission network 100 both in terms of how 
announcements are actually played and how they are 
individually addressed. This level of detail is localized in 
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the physical networJc 805, which determines which element an 
announcement resides on and how it is connected to the 
specified leg. The physical network 805 accepts a play 
announcement instruction with a specified announcement 
5 identity and a leg within a dialog to connect the 
announcement to. 

It is necessary to be able to collect digits from a 
leg of a dialog. Again how the actual detail of how this is 
achieved is localized within the physical network 805. The 
10 physical network 805 accepts an instruction to collect digits 
for a specified leg withm a dialog. An announcement 
identity may be provided as a prompt to be played to the 



user. 



A dialog can be ended in its entirety by using an "end 
15 dialog" operation on the physical network 805. This causes 
the dialog to be closed and the network resources that may be 
involved to be released. 

^- 3- 4 Physical Netwnrjf R^sourcP M loca1-n7- 

^° knowledge of the presence and capabilities of the 

physical network elements is isolated from the services. 
Consequently, a service does not request a particular element 
to perform an action, merely that the action be performed, 
e. g. play announcement. How the announcement is played 
25 requires that a decision is made based on the knowledge of 
the capabilities of the physical element currently involved, 
what other physical elements are capable of performing 
particular actions and which ones may work together. This is 
the responsibility of the physical network resource 
30 allocator. The resource allocator must ensure that the legs 
involved in a call across elements are maintained. 

The schematic in Figure 7 represents this graphically. 
For any operations requested of the physical network 805 the 
allocator 700 shall determine the resultant operations on 
35 appropriate vir-ual encapsulations. 
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1. 3. 5 Physical Network Access 

All networks have users. Users exist in the physical 
domain. Physical network access is understood as the means 
whereby a user connected to the transmission network 100 is 
5 conveyed to the SDI physical nerwork 805. 

There are two modes of access to the SDI physical 
network 805 - dedicated and switched access. Dedicated 
access is defined as the case where calls arrive over a trunk 
that is a dedicated connection between an encapsulated 
10 nerwork element and customer CPE. Switched access is defined 
as the case where calls are switched through the physical 
transmission nerwork 100 and arrive at an encapsulated 
physical element over a common trunk. 

All accesses arrive at the SDI 200 with enough 
15 information to form the physical node address. It is possible 
to determine the country and/or area of origin from the 
physical node address and the calling line identity (CLI). 

An access shall be rejected if any of the following 
are asserted: 

20 • the virtual encapsulation is in a disabled stare; 

• the physical node address is not known; 

• the physical node is not in an enabled state; 

A rejected access shall be connected to an 
announcement stating that access has failed, played in the 
25 SDI pre-selected default language. A rejected access is 
logged m the SDI Log. 

1. 3. 5. 1 Dedicared Access 

Dedicated access is possible on dedicated access lines 
30 associated with a particular physical node i. e. an SSP trunk. 
The physical node exhibits the attribute of being dedicated; 
it is by this attribute that an access from that node is 
recognised as a dedicared access type. 



35 1. 3. 5. 2 Switched Access 

Access from a PSTN or over networks of other network 
carriers is possible. Switched access calls arrive at a 



wo 95/23483 



PCT/GB95/00421 



- 25 - 

physical node exhibiting the attribute of common and by merit 
of this are recognised as the access type "switched". Calls 
originated from the same station, using switched access, do 
nor always arrive at the same physical node. 
5 A call arrives at an SDI common physical node because 

an access number is interpreted by the carrier as identifying 
the call as an IN call to be carried by the network operator 
having the SDI 200. This access number may be either the 
number dialled by the user or the calling line identity of 
10 the originating station. For switched access the physical 
node address is the access number. 

1 . 37 5. 3 Travellers Access 

A traveller is a concept only understood within a 
15 service and not to the SDI. To the SDI 200 it is merely 
switched access. A service must deduce that an access is 
"traveller" and process the call based on what a traveller 
means within that service. 

20 1. 3. 6 IP Switch Behaviour 

An Intelligent Peripheral (IP) Switch may be used to 
connect voice trunks to IP resources, e. g. the Speech 
Applications Processor (SAP). The connection of resources to 
a particular voice trunk is controlled by the SDI 200 

25 depending on what action the service is requesting. 

In the UK PSTN, an IP or SN switch may have up to 
sixteen 30 channel voice trunks to a DMSU, Calls are set up 
to the voice trunks by a C7 NUP Dialog between the DMSU and 
the service node. The switch and its resources are accessed 

30 by use of the service node SLEE API. 

1. 4 Virtual Networks 

The concept of bringing together remote hubs of a 
telecom network as one integrated network is proven in many 
3 5 large corporate voice and data networks. Linking remote 
systems requires a transmission network; either to be built 
or bought. The net effect is the appearance of a single. 
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dedi cared network of users. Each dedicated virtual network 
offers particular capabilities based on what physical 
elements are available within it, and, extending to the IN 
domain, what IN services are available to it. The addresses 
5 of locations within a virtual network are logical 
representations and are translations from other logical 
representations of physical addresses. This address 

translation provides the power to separate virtual networks 
from physical networks. 
10 A virtual network can be viewed in the same way as any 

other network, the main difference being that a virtual 
network is unaware of its physical construction. It can be 
viewed like a cloud, through which there is always a route 
from point A to point B but only the transmission network 
15 knows what it is - it may be dynamically changing. The 
connection routes are transparent (ie not known) to users. 

A virtual network has people that use it - users. 
They use some form of station on the network, e. g. a phone, 
a terminal etc. The stations are connected to a node, e. g. 
20 a private PBX, a termination point in the public telephony 
network, a channel in the cellular network etc. Nodes are 
located at sites. The virtual network in this context and in 
the context of embodiments of the present invention is the 
interconnection between these nodes. A virtual network 800 
25 is configured to have services. A service is a particular 
communications capability, e.g. Plain Old Telephony Service 
(POTS), Voice Mail, etc. 

Each virtual network 800 has a numbering plan defining 
what it allows as directory numbers for its users and 
30 stations. The definition of a network specific numbering 
plan gives the virtual network concept the power to represent 
practically any type of network. The associations of users 
and directory numbers is maintained within a virtual network 
user directory. What part of the "world" a user is in is 
35 maintained in an atlas, where world means whatever is 
perceived by the administrator of the virtual network. Users 
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have some or all services available to them; the services a 
user has is maintained in a user profile. 

As provider of virrual networks, a carrier or network 
operator will create, enable, modify, disable and delete 
5 them. Each virtual network has a unique virtual network 
identity. Customers are able to, when allowed by the network 
operator, modify some aspects of the virtual network. 

1. 4. 1 Virrual Node & Virtual Node Addregs 
All virtual networks have nodes to which stations are 
connected. From within the virtual network a node is an end 
point e.g. a local PBX or phone jack. (As opposed to the 
physical network perspective which describes the actual trunk 
or line). _Thus the same node is known by a physical node 
15 name and a logical virtual node name. This decouples 
knowledge _ of the physical network configuration from the 
virtual network. An association must be maintained but the 
virtual network only needs to know about its own virtual 
'nodes . 

20 Each virtual node in a virtual network 800 has a name. 

The virtual node name is unique within the virtual network. 
Every virtual node name has a virtual network address which 
IS unique within a virtual network. Virtual nodes and their 
addresses are defined further, later in this specification. 

25 

1. 4. 1. 1 Gateway Nodes 

A particular type of a virtual node is the gateway 
node which carries calls off the virtual network 800 to 
another network (public network or virtual network). Gateway 
30 nodes behave as any other virtual node. 

1. 4. 1. 2 Site? 

A site is the place where a node is located. A site is 
3 5 synonymous with virtual node. No distinction is made between 
site and virtual node. 
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10 



1. 4. 2 Virtual Network Address 

There may be one or many stations connected to a 
virrual node. It is necessary to be able to identify a 
particular station. A virtual network address uniquely 
identifies a station on the virtual network and comprises a 
virtual node address and a station number. Every station on 
the network has a virtual network address. 

4. 3 Virtual Nerwork Numbering Plan 
Every virtual network has a numbering plan which 
defines valid directory numbers, dialling procedures 
(prefixes, etc. ) and the maximum length of numbers. Prefixes 
may be defined to indicate out of plan numbers. The 
numbering plan may be divided into any number of ranges or 
15 cells, up to maximum number length - 1. A numbering plan 
only describes virtual network directory numbers, not where 
they terminate or what they translate to. 

The number of entries in a numbering plan (or sub-part 
of it) is limited by the number of digits available and the 
20 definition of what a valid directory number is. 

Numbering plans support vanity numbers, i. e. numbers 
thar spell words using a commonly accepted alpha - number 
mapping. 

The numbering plan is able to encapsulate numbers from 
25 other numbering plans e. g. public numbers enabling on-net 
stations to have off-net type numbers. 

1. 4. 4 Directory Numbers 

A directory number is a virtual network number. The 
30 identity of a user on the virtual network is his/her 
directory number (DN). The directory number for a user may 
be determined from the station he uses or by explicit 
identification through an authorisation code and personal 
identification number. A DN is unique within a virtual 
3 5 network. Every station on a virtual network has a Directory 
Number. A DN identifies the virtual network to which it 
belongs. Directory numbers can be of variable lenath uo to 
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the maximum length defined in the numbering plan. Directory 
Numbers may overlap, e.g. 12345 and 123456 are both legal. 
A directory number is a logical entity and is independent of 
a particular node or service on the network. 
5 The virtual network administrator is able to add, 

enable, disable and delete directory numbers. 

1- 4. 4. 1 Associations of DNs: the Virtual Network 

Atlas 

A virtual network may be global, national or local and 
an administrator may need to define the world of that virtual 
network, which may or may not be the same as established 
political or national boundaries. The location of a virtual 
network directory number in the world of that virtual network 

15 is the virtual network atlas. The atlas permits a virtual 
network administrator to define associations of DNs. 

These associations may describe any relationship e. g. 
originating geographic area, special interest groups, etc. 
There is no limit to the number of directory numbers that may 

20 be grouped together. There is no limit to the number of 
associations that may be established. Services determine 
what association a direcrory number belongs to. A directory 
number may only appear in one association. 

The virtual network administrator is able to create, 

25 modify and delete associations of DNs. 

1. '4. 5 Virrual Network Mumber Directory 
The DN is defined as a logical, unique identity of a 
station on the virtual network. Generally, in telephony, a 

30 user is associated with a particular station, and when a 
user' s DN is dialled, the caller would expect that user' s 
station to "ring". (Of course, which DN is targeted and, 
consequently, which station actually rings is the 
responsibility of a service. ) 

^- Stations are connected ro nodes and, as the earlier 

discussion on Virtual Network Address (Section 1.4.2) 
defined, are addressed by a virtual network address. It 
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will, therefore, be necessary to associate a particular 
virtual network address with a particular directory number. 

There is a direcrory of associations of virtual 
network addresses to DNs, i.e. a virtual network number 
5 directory. An entry in this directory is a virtual network 
address - directory number pair. There is one of these 
directories for a virtual network. 

Where an entry is in the directory, it is possible to 
obtain from it, one, and only one, DN for a particular 
10 virtual network address. Similarly, it is possible to 
obtain, one, and only one, virtual network address for a 
particular DN. A DN may be marked in the directory as 
enabled or disabled. 

A virtual network administrator is able to add, 
15 enable, disable, modify and delete directory entries. It is 
possible to view directory entries on a particular virtual 
node. 

1. 4. 6 Users & Stations 

A person (or otherwise) that has legitimate access to 
a network is a user of that network. A user has a name, some 
form of identity, and other attributes that describe him. A 
user uses a station to interact with the network, and would, 
generally, have a normal (default) station. In line with the 
25 earlier discussion on virtual networks (Section 1. 4 on Page 
20), a station is an origination or termination point 
connected to a node on the network. 

To other users, a user has an identity on the network 
- say, a directory number, and, by this identity he is 
30 recognised and other users on the network can address him. 
Further, in conventional telephony, it is the station that 
has the directory number and the actual user is inferred from 
the directory number. 

A user may wish to access his service from a station 
35 other than his own (provided the service enables him to do 
this). In this case, his identity cannot be inferred and 
must be inquired. The user needs to identify himself to the 
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nerwork, e. g. by means of an authorisation code (e. g. a 
calling card number) and a personal identification number. 
The circuns tances when identification is required are 
governed by services. 
5 Generally, a user' s station has a default service, 

e. g. a PBX line usually provides dial tone for voice service 
as opposed to, say, voice mail service. Consequently, 
therefore, it can be said that the directory number of a 
station is associated with a' user and with a particular 
10 service that the user has. Thus, a station is described by, 
and to a user is synonymous with, a directory number. 

Every user is described by a user profile containing 
informatioTi about the individual and which directory numbers 
that a user_ has. Each directory number identifies a service 
15 profile which is the capabilities of a particular service for 
that user.^ Unless a service determines otherwise, the user 
is identified from the directory number of the station. 

The virtual network administrator will add, modify and 
-delete the profiles describing users. A user profile 
20 exhibits a state of enabled or disabled which is set by the 
virtual network administrator. 

4. 4. 7 User Profiles 

It is necessary to hold certain information about a 
25 user, within the SDI 200, that is required across many 
services. The information, considered to be non-service 
specific, that is held per user is: 

• User name, an ASCII text string of up to 50 
characters. 

^0 • A user identity, an ASCII key of up to 20 

characters . 

• An authorisation code 'and PIN, a digit string up to 
20 characters (including PIN). 

• Authorisation status; one of enabled, blocked or 
35 disabled. 

• Network operator Account number, a digit string up 
to <?> characters. 
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• Network operaror Calling Card number, a digit 
string up to <?> characters. 

• Cusrcmer Type Identifier, a single digit identifier 
*' B" (business) or " P" (personal). 

5 ♦ User stare, a single digit identifier describing a 

stare of enabled or disabled. 

• A Directory number keyed list of schedules of 
services. 

User profiles are addressable by the user identity^ 
10 aurhorisation code or by one of the directory numbers that a 
user possesses. User profiles are persistent. Each DN that 
a user has within his profile has a schedule. The DN 
schedule identifies a particular service profile for a 
particular time of day. Referring to Figure 9, one service 
15 profile 900 is always identified. 

The service profile description associated with a DN 
contains: 

• A time expression detailing the time that this 
service profile is active. 

20 •A default service profile indicator, marking a 

profile as the default for this DN. 

• A service profile identifier referencing the actual 
service profile. 

• A service identifier indicating the name of the 
25 service the service profile describes. 

The service profile referenced does not have to be 
exclusive to this DN and may be used by any number of other 
DNs, provided the service itself is shareable (this is the 
decision of those provisioning. The SDI 200 does not provide 
30 any form of logic checking on the sharing of service profiles 
900 ) . 

Once a user profile exists it is nor possible to 
modify the user id, all other components may be changed. 

The virtual network administrator is able to create 
35 and delete user profiles. User profiles may only be deleted 
when the directory number list is empty. User profiles are 
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modifiable by a virtual network administrator. A user may 
modify the authorisation code and PIN. 

1. 4. 8 User Directory 
^ Every user on a virtual network has a user profile 

within that virtual network. User profiles are held within 
a user directory. It is possible to locate one, and only one, 
user profile in the user directory using the following 
individual keys; 
^0 • User identity. 

• Authorisation code. 

• Directory number. 

Thus, for a given DN it is possible to obtain, from a 
user profile, a service name and a service profile identifier 
(and, indeed, any other information in a user profile). 

User profiles may be added to, replaced within and 
deleted from the user directory by the virtual network 
admi ni s t rater. 

1- 4. 9 Vir-ual Network Services 

This section briefly addresses two areas for the sake 
of clarity and completeness. Firstly, it relates concepts 
and processes of an IN Architecture and a service creation 
process. Secondly, and more pertinently, the section details 
25 the requirements describing how services are to be deployed 
within the SDI 200. This includes the delivery of a service 
to the Intelligent Network Element and the activation of a 
service within the domain of a virtual network. 

30 It might be noted that a service creation architecture 
suitable for use with the SDI is described in the present 
applicant' s co-pending European patent application number 
94302848.0, filed on 21 April 1994, the subject matter 
disclosed therein being incorporated herein by reference. 

35 Other service creation architectures or environments could 
however be substituted. 
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It mighr also be noted that an IN architecture is not 
essential to support ernbodime'nts of the present invention. 
It IS, though, important to design in suitable interfaces for 
the SDI 200. 

5 A service, vithin the context of the intelligent 

network element, is a specific logical set of 
telecommunication capabilities that have been packaged and 
made available to be deployed on a virtual network, e. g. 
voice services, voice mail, fax store & forward etc. A 
10 service is accessed by a user through his virtual network. 

Services are separately developed entities to which 
the SDI 200 interfaces. A virtual network 800 supports more 
than one service. 

The IN Architecture and various SCE requirements rely 
15 on reusable software componenrs which are not specific to any 
one service and which are used as the parrs from which 
services are assembled. Referring to the above-mentioned co- 
pending application, these components have been termed 
Generic Service Components (GSCs). GSCs are developed, 
20 tested and released by engineers using an SCE tool-set and 
test harnesses. GSCs targeted for deployment at the IN 
Element, are conveyed to the IN Element and deposited in a 
Feature Library. 

Services are designed and constructed, to a specific 
25 set of requirements, by service designers using different SCE 
tools and processes. Service designers can use GSCs made 
available to them by the SCE as above. Once constructed and 
tested to be network worthy, the service must be deployed in 
zhe appropriate elements in the IN Architecture. 

30 

1- 9. I SDI Service Enaine 

Services, zo mterwork with SDI, are developed to 
operate within the confines of an SDI service engine 825. 
The SDI service engine 825 provides a bounded environment and 
35 defined interface within which services run. The interface 
enables services to avail of resources outside that boundary, 
e.g. the virtual network directories, the physical network. 
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physical interfaces to other operational support systems etc. 
The service engine 825 performs all the necessary correlation 
of the GSCs in the feature library with those used in a 
s ervi ce. 

5 The service engine 825 performs service discrimination 

for a call. Once the target service is identified the 
service engine executes the appropriate service. The service 
engine provides to services a mechanism for maintaining call 
context. 

10 A novel aspect of embodiments of the present invention 

is the use of a software "blackboard" technique in the SDI 
service engine 825 and is described later in more detail. 

1. 4. 9. 2 Servi ce Dictionary 

15 A virtual network has a specific set of services. 

These services are added by the BT IN administrator. The 
collection of services available to a virtual network is 
localized in a Virtual Network Service Dictionary, For every 
Service that a virtual network has, there is a corresponding 

20 entry in its service dictionary. The entry in the service 
dictionary fully describes that service. An entry in the 
service dictionary holds: 

• the distribution media version of the service - the 
service package; 

25 • the installed service; 

• the directory of all that service' s profiles 
describing how the service operates. 

1. 4. 9. 3 Service Package 

30 Services are delivered to the SDI 200 in a 

distribution media format which is termed the service 
package. The form the media will take will not have any 
dependency on the contents of a service package. The service 
package provides all that is required to install a service 

3 5 into a virtual network 800 for use by the SDI service engine 
825. A service package does not contain executable code. A 
service package references existing executable components in 
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the SDI feature iitrary. The service package defines the 
order of execution of those referenced features. The service 
package defines the profile description of the service. The 
service package is the defined service interface between the 
5 SDI 200 and the SCE 210. 

1. 4. 9. 4 SDI Service 

A service is considered to be a unique entity which 
only has meaning within the context of a particular virtual 

10 network 800. Therefore a virtual network 800 must exist 
before a service can be deployed within the SDI 200. 
Irrespective of the similarity of two services, either in 
construction or behaviour, on two virtual networks, they are 
two distinct, and to all intents and purposes, different 

15 services. 

An SDI service is an executable application that can 
process calls. The SDI service is constructed from the 
service package to form an executable application. The 
service engine 825 performs the linking of all the referenced 
20 executable components which the service package states 
comprise the service. The installed service is controllable 
through a management interface which shall make it possible 
to: 

• query or set the control state of a service which 
25 is one of enabled or disabled; 

• query or set the state of a feature; 

• iterate over the features in a service, i. e. move 
to the next feature without knowing its name; 

• query and set the service name; 

30 • query and set the Billing identity for a service; 

• query and set the ordering of feature execution 
within a service; 

• query and set the resources of a service, e. g. the 
maximum number of permitted simultaneous calls. 

35 
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1. 4. 9. 5 Service Profile Directory 

Every service available ro a user on a virtual network 
800 is described by a service profile. Service profiles are 
stored in a service directory. It is possible to locate one, 
5 and only one, service profile in the service directory using 
the following individual keys: 

• Service profile identity 

A service profile may be added to, replaced within or 
deleted from the service directory. 

10 

1. 4. 9. 6 Service Profiles 

A service profile defines the particular behaviour of 
a service and is the required description of that service as 
configured for a user, or group of users. A service profile 

15 is persistent. The contents of a profile are specified by 
service designers and are not understood by SDI. While the 
contents are not understood there are several things that SDI 
requires to read from every service profile, namely, the 
"service name and the state of the service profile i. e. 

20 enabled or disabled. Service profiles are provisioned over 
the provisioning interface, service designers stipulate what 
users' modification rights exist. A service profile is 
addressable by a unique service profile identity. 

25 1. 4. 9. 7 Adding A Service to a Virtual Network 

A service can be added zo a virtual network, provided 

the service exists in a library on the network element; a 

service may be deleted from a virtual network. All services 

have a control state of enabled or disabled which a virtual 
30 network can read; this stare is modifiable by the BT 

administrator (or maybe, by the service itself). 

Referring to Figure 4 7, the steps involved in adding 

a service to a virtual network 800 from the SCE 210 can be 

simply set out as: 
^5 i) creating a service profile and deploying it at the 

virtual network 800 (STEP 1); and 
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ii) updaring the user profile with a VDN and service 
profile reference and deploying the updated user profile to 
the virtual nerwork 800 (STEP 2). 

In more detail, before a service becomes available to 
5 any user on the virrual nervork 800, the following must 
occur: 

• the media version of the service entered into 
s e rvi c e di c ti onary ; 

• the service must be installed into the virtual 
10 network. 

• the service must be given to a particular user. 
The virtual network 800 has an operation to add a 

service. This operation expects a service package. The 
operation of adding a service causes an entry to be created 
15 in the service dictionary and the service package to be 
placed there. 

The virtual network 800 has an operation to install a 
service within a service dictionary. This operation fails if 
either the service package is not present or if the installed 

20 version of the service is newer than the service package. 
The latter condition may be explicitly over-ridden. The 
action of installing a service does not affect any profiles 
for that service. Any necessary profile migration is 
performed by a separate means. Installing a service on the 

25 virtual network strips the necessary information out of the 
service package that is required by the service engine i.e. 

• the feature (component) references; 

• the feature order of execution; 

• specific resource information (e. g. max. 
30 simultaneous calls); 

• the billing identity and name of the service 

• the service control state (i. e. enabled, disabled 

etc. ) . 

The install operation causes the service engine 825 to 
35 perform the necessary actions to retrieve referenced 
components from the feature library and readv them for 
execution. If the service engine is unable to make a service 
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ready for execution the operation of installing the service 
in the virtual nerwork 800 is deemed to have failed. 

The virtual network install service operation also 
causes the allocation of the necessary resources within the 
5 SDI 200 in accordance with the resource specification in the 
service package. 

Service profiles for the service are constructed and 
edited at the SCZ 210 as defined for the particular service 
and delivered to the Service Profile Directory through the 
10 provisioning interface. 

1-4.10 Virtual Network Se rvice Access 
From the discussion on virtual nodes and virtual 
network address (Section 1.4.1 and Section 1.4.2) it follows 
15 that a virtual network 600 is identified by the time these 
are deduced. (The discussion on what is required to identify 
a virtual nerwork 800 is covered in Section 1,5, "Networks 
Interconnection" below. ) 

A virtual network can be viewed as a community of 
20 users. A virtual node address does little more than to 
pinpoint the community. A virtual network address uniquely 
identifies an individual within the community. 

The virtual network has the responsibility to identify 
a particular service. Services understand DNs; services have 
25 no concept of virtual network address. 

Referring to Figure 11, the access information that a 
virtual network 800 requires, for an origination from the 
physical network, is the virtual network address. From that, 
the virtual network number directory (Section 1.4.5) is 
30 capable of deducing a DN. It has been previously stated that 
a virtual nerwork, virtual node address, a virtual network 
address and a directory number all exhibit a state of enabled 
or disabled. If any of these states should be disabled for 
a given network address then access is denied. When access 
35 is denied the caller is connected to an appropriate 
announcement and an entry is made in the SDI log. 
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The DN is a key to a service name and a service 
profile (see rhe earlier discussion on user profiles; Section 
^•4- 7). The service profile gives the service the 

inf orir.arion required to handle this call for this user. 

4. 11 Virtual Network Toll Ticket Collector 
Services require to send charging information, in the 
form of call detail records, to the appropriate billing, 
systems. A call detail record may be one or a number of toll 
tickets produced by the service. The service designers 
define what a call detail record is. 

A service places toll tickets with the Virtual Network 
Toll Ticket Collector. The contents of a toll ticket is 
defined by the service designer and is not understood by the 
15 SDI 200, however, it is possible for the SDI 200 to read the 
following about a toll ticket: 

• the dialog identity producing the toll ticket; 

• the toll ticket sequence number within the dialog; 

• the service name producing the toll ticket; 

• the type of toll ticket being one of: {Solo, First, 
Intermediate, Final} 

When a service is added to a virtual network 800 it is 
able to (and, indeed, must in order to send toll tickets): 

• register a service name with the toll ticket 
25 collector; 

• register one of a possible set of toll ticket 
handling instructions . 

The toll ticket handling instructions tell the 
collecror what to do with toll rickets produced by a service 
30 and is one of: 

• automatically forward all toll tickets upon 
receipt; 

• automatically forward complete toll ticket sets. 

• When polled, forward all toll tickets; 

• when polled, forward complete toll ticket sets. 

A complete toll ticket set is either a solo toll 
ticket or a sequence for which a final toll ticket is 
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present. The virtual network toll ticket collector 

automatically purges toll tickets once delivered to the SDI 
billing interface. 

5 1,5 Networks I nter connect ion 

Referring to Figure 12, the physical network 80 5 
describes the entities in the physical network. The virtual 
network 800 describes the nodes in each virtual network. 
There is a network interconnect 810 maintaining the 

10 connectivity information of how each virtual network 800 
relates to the physical and other virtual networks. The 
network interconnect 810 handles originations and dialogs 
with the physical network identifying virtual networks; and 
liaises with the physical network 805 on behalf of virtual 

15 networks 800. 

1. 5. 1 Virtual Node 

Referring to Figure 3, a physical node in the physical 
network 80 5 has users of a virtual network 800 connected to 

20 it. That node must be identified in some manner to the 
virtual network. There is a logical means of referring to 
physical nodes, thereby decoupling the physical network 805 
and leaving the physical network operator free to manipulate 
node assignments. 

25 The virtual network 800 has virtual nodes 310. These 

are the only nodes a virtual network 800 is cognizant of. 
Users are connected to a virtual node 310 on the virtual 
network 800. Each virtual node 310 has a name and a virtual 
node address . 

30 Virtual nodes 310 have originating and terminating 

attributes, which may be undefined. Undefined originating or 
terminating attributes signify that a node is incapable of 
carrying originating or terminating calls respectively. This 
enables the virtual network 800 to distinguish between 

35 different origination and termination behaviour for a user of 
the virtual network 800. 
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Virtual nodes can be created or deleted only by the 
nerwork provider or operator for any virtual network 800. A 
virtual node 3 10 can exhibit a state of enabled or disabled. 
The network administrator of the network operator is able to 
5 modify the stare of a node. All new nodes are created with 
a state of disabled until explicitly enabled. a virtual 
network administrator is able to view virtual node 
information but unable to modify it. 

10 1. 5. 1. 1 Virtual Node Address 

Every virtual node 310 has and is referred to by a 
virtual node address. A virtual node address indicates the 
virtual network identity and the node name, or number, within 
that network. 

15 

1- 5. 2 Virtual Network Discrimination 

All calls arrive at some physical node 305 in the 
physical network 805. It is necessary to determine which 
virtual network 800 should handle the call. 
20 Virtual network discrimination is achieved through the 

identification of the virtual node 310 that is associated 
with a particular physical node 305. The virtual node 
address indicates the virtual network identity. 

A call is handled by a virtual network 800 if and only 
25 if all the following are asserted: 

• the physical node address is one that is known; 

• the physical node address is associated with a 
virtual node; 

• a valid virtual network can be deduced; 
30 • the virtual network is active. 

1- 5. 3 Physical Node to Virtual No de As^nni^j^^n^ 
The network interconnect 810 maintains the 
relationships between physical nodes 305 and virtual nodes 
35 3 10. It is possible to associate a maximum of two physical 
network nodes 305 with one virtual network node 310 - one 
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being the originaring afliribute and one being the terminating 
node. 

This reiarionship is provisioned by the administrator 
of the network operator. 

5 

1. 5. 4 Access Numbers for Switched Access 
An access number is a public number that is known to 
the network operator and customers as a VN access number. 
The access number can be either the number called (the 
10 dialled number) or the number called from (the calling line 
identity). An access number is to the SDI 200 a physical 
network address. An access number is treated just like a 
physical node 305 and associated with virtual nodes 310 as 
previously described. 

15 

1. 6. Time Requirements 

The SDI 200 maintains a network time which is 
available to ail components and services. The network time 
is that time that is chosen for the network to operate on and 
20 is not necessarily the local time. By use of the appropriate 
delta value from network time, services and components are 
able to deduce a local time - if required. The SDI time has 
a granularity of one millisecond. 

25 1. 7 Persistence Model 

The SDI 200 provides a persistence model for objects 
of virtual networks 800, the physical network 805, network 
interconnect objects and service objects. The persistence 
model shall manage the storage of all persistent objects. 

30 All managed persistent objects shall be addressed in a 
Managed Information Base (MIB) (not shown). The persistent 
store is capable of supporting real-time service 
applications. 

It will be understood from object oriented 
35 environments that managed objects are objects in which data 
is encapsulated by management process software. 
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The persistence model provides for local backup. 
Services are nor mvasiveiy affecred by backups and onerare 
normally during a backup. Backups may be scheduled in 
advance. Backups can be specified to the following levels 
5 of granularity: 

• Full 

• Physical Network 

• Network Interconnect 

• Virtual Network(s) 
10 • Feature Library 

• User Profiles of Virrual Network(s) 

• Service Profiles of Service (s) of Virtual 
Network (s ) 

• Number Directory of Virtual Network(s) 
1^ • Service Package (s) of Virtual Network(s) 

Restoration of backed up information will cause a 
change in behaviour of the items being restored to reflect 
their state at the time it was backed up - restoration of 
data is an intrusive activity. 

20 

1. 8 st?t-?t:ig? 

The requirements for statistics collection and reporting will 
vary according to e. g. network operator and are not detailed 
25 here. 

Components maintain their own statistics. Components 
emit statistical information when requested. 

Services would be expected to have specific 
requirements for statistics collection. 

30 

1. 9 Log 

The SDI 200 has a log utility which all other 
components can use to log acriviry and event messages. The 
log utility interfaces with the UNIX (computer hardware 
35 operating system developed by AT&T) file system. 

Log messages are of variable length. Log files are in 
ASCII format. 
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It is possible to determine the following for each log 
mes s age: 

• Log Message Idenriry - a unique sequence identity. 

• Time sramp - a time expression recording the time 
5 of the evenr. 

• Message Type Name - one of {Exception, Activity} 

• Logging Component Name - the name of the component 
producing the log event, 

• Customer Context - as much information that is 
10 known about the customer when the log event is generated e. g. 

virtual network identity, directory number, user identity, 
service profile identity etc. 

• ASCII readable Text - The actual message. 

Log files roll over at the end of a specified log 
15- period or when the log reaches a specified size. Log files 
are given a specified amount of disk resource within which to 
exist so that the operation of the node is not stopped by 
.proliferous log messages. When log resource reaches a 
threshold the oldest logs are automatically purged ensuring 
20 new log messages are not lost. 

All components are able to place messages on the log. 
It is possible ro retrieve log messages. 

It is possible to produce reports of logs and 
establish queries for the reports through a human/machine 
25 interface (HMI) screen. Log report criteria can be 

constructed from compounded conditions of: 

• Time period 

• Message types 

• Component name 

^0 • Customer (virtual network) 

The management of logs is provided i. e, 

• It is possible to force close and restart of a 
named log. 

• It is possible to delete an unopen log. 

35 •, It is possible to specify a retention period. 

• It is possible to specify the roll-over period 

• It IS possible to specify the roll-over size. 
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• It is possible to specify the resource limit for 

logs . 

• It is possible to ser a percentage threshold for. 

The log informs network management 820 of creation, 
suspension, closing, deletion and roll-over of logs. Network 
management 820 is informed when a threshold resource limit is 
reached. 



10 i. 10 Process Management Control 

The components of the SDI 200, and services that run 
under its auspices, are all contained within a finite ser of 
manageable processes on the target platform. These processes 
are managed in two ways, i. e. invasively by an operator or 
15 automatically by heartbeats. 

Every managed process is required to respond to a 
heartbeat. Failure to respond to a heart-beat for a 
configurable, consecutive number of times causes an automatic 
management action to be executed. The action can be 
20 configured and is one of: 

• restart 

• kill 

• suspend 

• (other actions?) 

25 Invasive operarions by an operator are possible. Each 
managed process accepts the following stimuli for the 
purposes of process control: 

• suspend (Go Out of Service) 

• resume (Come In Service) 
30 • reinitialise 

2. SYSTEM INTERFACES 



It is clear that the SDI 200 has to provide or 
35 interface with a wide range of nerwork systems, such as 
Billing, these being provided overall by the intelligent 
network (IN). Referring to Figure 10, the SDI has various 
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sets of interfaces to support the deployment, operation and 
management of IN services. The system interfaces can be 
categorised as: Transport Network Interfaces 1010; Service 
Creation Architecture Interfaces 1000; Operations & 
5 Management Network Interfaces 1030; and Human Machine 
Interfaces 1020. 

The interfaces to SDI will comprise those required to 
support the IN services to be deployed. 

The transport network interfaces are discussed here as 
10 an example only. The interfaces to the physical transport 
network will be constrained by circumstance as well as by the 
design philosophy and strategy of SDI. Overall: 

i) "the SDI provides an abstraction of the physical 
transport network so that virtual networks and services can 

15 be created without requiring cognisance of the physical 
topology of the transport network; 

ii ) the SDI is an extensible and evolvable product; 

iii) the SDI in the present embodiment of the 
"invention accesses the transport network resources through a 

20 service node service logic execution environment; 

iv) it is the interfaces to the transport network 
necessary to deliver the IN services actually to be deployed 
which are required. 

The requirement that the Service Node SLEE is used 
25 forces these interfaces to be expressed in terms of SLEE API 
commands. This prevents the fulfilment of total virtual 
encapsulation within the SDI. In general, the SLEE is used 
to provide the physical interface to the devices. Thus, for 
example, although a DMSU network (switch) interface is 
3 0 physically C7 NUP to SDI the DMSU appears as a device that is 
driven by a subset of the applications programming interface 
offered by the SLEE. It is in terms of this API that the 
transport network interfaces are specified for the SDI on the 
SN platform. 
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2. 1 DMSU Interface 

The DMSU 110 is a Tandem switch in the UK PSTN 100. 
The DMSU 110 will pass IN calls to the SN 125 for processing. 
This is the only interface to the PSTN 100 that is provided. 

5 

2. 2 SAP Interface 

The Speech Applications Processor 1035 is an 
Intelligent Peripheral (IP) device connected to the service 
node 135 and hosts a set of interactive speech applications, 
10 used to solicit information from a telephone caller. The 
SDI-SAP interface will be realised through the use of a 
suitable Applications Programming Interface. 

The remaining interfaces are each constrained by the 
15 particular proprietary equipment to which they are connected 
and are not further detailed herein. Other proprietary 
situations would require different interfaces. 

3. SDI MODEL 

20 

Referring to Figure 13, the context of the SDI 200, in 
relation to a transmission network and associated systems, 
and major components of the SDI are shown. The SDI 200 uses 
the SN SLEE to interact with ail transport network devices. 
25 The management network 820 uses the SLEE to interact with 
appropriate external network management systems. 

Service creation interfaces are encapsulated within 
the management nerwork sub-system 820. 

As mentioned above, the SDI 200 virrually encapsulates 
30 the transport network 100 in a physical network system of 
interacting objects. The physical nerwork 805 is a 
representation of network capability and hides network 
topology and protocols. The SDI physical network 805 
presents a consistent network operations interface to the 
35 rest of the SDI 200 for interaction with the transmission 
network 100. 
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The Network Interconnect component 810 of the SDI 200 
maintains the connectivity information between physical and 
virtual networks 805, 800 and provides for the 
interconnection between all networks. The Network 

5 Interconnect performs network discrimination. It presents 
the same consistent network operations interface. 

IN services run in the Service Engine Governor sub- 
system 825. For the sake of performance, service execution 
is grouped into one sub-system rather than provide a service 
10 engine within each virtual network. The service engine 
governor sub-system 825 performs service discrimination and 
service execution. One could take the logical view that the 
service engine of each virtual network is centralized into 
one objecl^ for the sake of efficiency in a real time 
15 environment. The service engine governor subsystem 825 has 
libraries _of service application features, provisioned by the 
SCE, that are referred to by Marketable Service Features 
within a Service Package. 

20 3. 2 The SDI Transaction Prorncnl 

As described, the SDI 200 can be viewed as a set of 
networks and resources. Networks and resources within a 
network communicate with each other using defined protocols 
and message sets. The SDI 200 has a defined protocol for 

25 communication between resources and networks: the transaction 
protocol. In the context of the SDI 200, a transaction 
protocol resource is any element which is capable of being 
involved in a communication using the SDI transaction 
protocol. The SDI transaction protocol defines how resources 

30 talk to each other and what they say. 

Resources converse using the transaction protocol. 
The conversation can include any number of resources but that 
conversation must be focused relative to a particular 
transaction, where a transaction is a discourse about one 

35 particular subject e. g. an IN call. The transaction protocol 
is transaction based, similar to the known Signalling System 
7 mechanism, where transactions can be opened using a begin, 
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continued using a conrinue operation and closed using an end 
operation. 

Referring to Figure 15, the complete conversation that 
resources 1500 have is a transaction. Each contribution to 
5 a transaction is termed a dialog. In "well-behaved" human 
communication a person must first obtain the "ear" of his 
audience and then deliver his message. 

In the SDI transaction protocol the attention of the 
target resource is gained by the use of begin, end and 
10 continue methods. The message is delivered to the listener 
is a dialog. 

Referring to Figure 28, the SDI Transaction Protocol 
2800 is the abstract base class for resources 1500. it 
provides for the behaviour of routing dialogs between 
15 resources 1500, and queuing dialogs until the resource is 
able to handle them. 

A transaction protocol resource 1500 can have a state 
of value-add mode. This enables it to realize that, although 
the dialog is not intended for this resource, it may have 
20 some value to add to it so as to make it meaningful to the 
target resource. A resource in value add mode scans the 
dialog' s parameters and adds any missing information to which 
the resource has access. Resources have status information 
and may be enabled or disabled. 

"^^e SDI Transaction Protocol 2800 provides for the 
handling of three different dialog transaction types: begin, 
continue and end. A begin is not possible if there is an 
entry in the open dialog list with the same transaction 
identifier. Continue and end are not accepted if the 
transaction has .-ot been opened. 



30 



3. 2. 1 Dialog 

Referring to Figure 16, a dialog 1600 is a commuting 
object that allows the exchange of information between two 
35 resources involved in a transaction. A dialog identifies the 
transaction to which it relates by the transaction protocol 
identity 1605. It contains the resource names 1610 that 
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correspond to the sender and addressee of the dialog. Also 
it has one or more operations 1615 to be carried out by the 
des tinati on resource. 

Operations 1615 can be added and removed to a dialog 
5 1600. There is no way to specify the order of placement of 
operations within a dialog. Operations 1615 are returned 
from a dialog in first -in- first -out order. The transaction 
Protocol does not enforce any order of processing of 
operations on a resource. 

10 

3. 2. 1. 1 Routing Dialogs 

Resources 1500 are grouped into resource areas. Each 
resource area has an area router, which is the only resource 
that knows, about resources in other areas. The resource 
15 naming convention is used to group resources and inherent in 
this convention is the area router for a particular resource 
group. 

Dialogs 1600 are routed based on the value of 
destination resource and originating resource. The 

20 originating resource most recently sent the dialog. Each 
resource only knows about the resources it has connected to 
it; and their area router. 

This information is stored in a routing table. 
Resources use the routing table to pass the dialog through 

25 the system. If the destination is in the routing table it 
proceeds to the destination. Otherwise, if there are two 
entries in the routing table it proceeds to the one not equal 
to the originating resource. If there are more than two 
entries in the routing table it sends the dialog to its area 

30 router. If the current resource is the area router, it sends 
the dialog to the network interconnect. 

3. 2. 2 Opeir^1;iQns 

Referring to Figure 17, operations 1615 are the 
35 mechanism by which resources 1500 have other resources 
perform some action. An operation 1615 can be to initiate 
some action or it can be the response to some previous 
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operation. The operations that are valid for a particular 
resource are dependent on thar resource. A resource rejects 
operations it does not understand. 

Every operation 1615 has a unique name 1700. 
5 Operations can have one or more parameters 1705 associated 
with them. 

There are a number of categories of operations 1615 
that are identified as required: 

• Connection Operations - those that are required to 
10 manipulate the parties involved in a particular IN call. 

• Announcement Operations - those operations to 
effect the connection of network resident announcements to a 
party in a call. 

• Collection Operations - those requiring the 
15 collection of information from a party. 

3. 3 Transpo rt Network Abstraction 

Referring to Figure 29, the SDI Transport Network 805 
is a virtual encapsulation in software hiding the detail of 
20 network elements, signalling protocols, call models, physical 
access mechanisms and changes to the transmission network 
100. The Transport Network Abstraction 805 is a Transaction 
Protocol Resource 1500 communicating internally and 
externally using dialogs 1600. 
2^ (Note the terminology of the components of the SDI 

physical network 805 shown in Figure 29 are either known from 
this specification or can be identified by reference to 
terminology of "he current UK PSTN. For instance, "RIDE" is 
a system for supplying recorded information from a 
30 distributed information environment. ) 

The physical network 805 operates on elements as 
requested by dialog operations and directs events from the 
transmission network 100. It localizes any specialized 
knowledge of individual physical network elements. The SDI 
35 200 ensures the graceful release of resources when a call is 
cleared. 
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Some limited physical artributes of a station e. g, 
display capabilities for caller name display are propagated. 
The physical elemenrs to which SDI must interface are 
virtually encapsulated in software. It is possible to have 
5 any number of instances of that element type, e. g. there 
could be N instances of DMSU representing the N actual DMSUs 
declared to SDI. Virtual encapsulations of physical elements 
can be created, modified and deleted as required to reflect 
the physical transport network 100. 

10 A virtual encapsulation is provisionabl e with the 

state information of the actual element, e. g. for a Speech 
Applications Processor (SAP) it reflects the SAP-identity and 
all application identities and parameters as configured by 
network op'erations. Each virtual encapsulation is 

15 addressable and state information is provisionable and 
modifiable" through the provisioning interface. 

3. 3. 1 View of Parties in a Call 

20 A call is a communication of some sort. A 

communication is considered only to be meaningful when more 
than one party is involved. All parties in a call need not 
be human e. g. a tone generator, an announcement player etc. 
Each party in a call is connected to some physical entity, 

25 this connection is termed a Leg of a call. 

Referring to Figure 18, a Leg 1800 represents a party 
in a call, both in terms of the physical and virtual network. 
The leg contains the physical network address 1805, virtual 
network address 1815, virrual directory number 1810 and 

30 station attributes 1820. 

All of this information may not be present when a leg 
1800 becomes known to the SDI 200; e. g, inbound legs will 
only have transport network information present. Leg 
information can be enriched by a number of resources within 

35 the SDI 200. Discussed here is a leg 1800 as a commuting 
object that is understood by Network Interconnect 810 and 
Service Engine Governor 825. 
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3. 3. 2. 3 CqXI^qX. O^qit? Op?ration5 

A service can request the collection of digits from 
Che originating leg of a dialog. For a collect digits 
request, the service engine governor 825 sends a "dialog 
5 continue message" to the network interconnect 810. The 
dialog contains the collect digits operation with the 
following paramerers : 1) originating leg; 2) number of digits 
to collect; 3) interdigit timeout; 4) total timeout. The NI 
8 10 passes the dialog to the physical network. This dialog 
10 goes to the resource allocator 2900. 

The resource allocator 2900 uses its resource 
capabilities table to determine whether the originating 
resource 1500 identified in the originating leg of this 
dialog can collect digits. If the originating resource can 
15 collect digits, the resource allocator 2900 sends a "dialog 
continue m^essage" ro the identified resource containing the 
collect digits operation and the parameters listed above. 

The originating resource must then translate the 
"collect digits operation request to physical hardware 
20 commands which instruct the resource to collect the digits. 

3. 3. 3 Access from the Transport Network 
All parties on a call use a station connected to a 
physical node. To the SDI 200 a physical node is a 
25 parricuiar trunk on a particular device in the transport 
nerwork. As, mentioned above, there are two modes of access 
to the SDI physical network 805 - dedicated and switched. 

3. 3. 3. 1 Physical Node 
30 Dedicated access is where calls arrive on a dedicated 

node. Switched access is where calls are switched and arrive 
on a common node. Each physical node is provisionable as 
dedicated or common. 

Referring to Figure 30, a SDI physical node 305 is a 
25 provisionable abstraction of a physical network element and 
a trunk that uniquely identifies a group of stations in the 
transmission network 100. It contains provisionable access 
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in the dialog to ensure the correct resource is used should 
a collect digits be the next operation. 

3. 3, 5 Use of Service Node SLEE 
5 Referring to Figure 20, the network operator SN SLEE 

2000 expects IN applications executing on it to 

• have knowledge of the transport network topology; 

• go to the SLEE to look for new call events; 

• only process one call at a time within one 
10 application; 

• suspend a call before looking for another call 

event; 

• use a specified API to interact with the network 
and manageinent elements. 

15 These points do not support the general principles of 

the SDI in which the services have no knowledge of the 
underlying network topology, are multi -threaded to handle 
^multiple calls simultaneously and expect to receive 
asynchronous unsolicited events from the network. 

20 In order to use the SLEE 2000 to feed the SDI call 

events, an SDI application will run on the SLEE. This 
application will solicit events from the SLEE and push 
commands back out to the transport network. There are two 
halves to the SLEE interface; an event gateway 2005 which is 

25 a SLEE application with the API bound in, capable of handling 
one call at a time, and a conversation resource dispatcher 
2010 which will dispatch events from the gateway 2005 into 
the SDI 200 and from the SDI 200 back to the gateway 2005. 

The SleeEventGateway 2005 is the main interface 

30 between the SDI 200 and the SLEE 2000. It retrieves call 
events from the SLEE call event queue. 

Call events may be inbound events from the transport 
network or outbound events from the dispatcher. The events 
are either passed them to the SDI for further processing or 

35 SLEE API calls are made to perform operations requested by 
the SDI on the physical network IF resources. It uses the 
call event message group and event type to determine what 
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Network resource interface objects. It also receives SDI 
Dialog messages from the SDI Physical Network resource 
interface objects requesting operations to be performed on 
the SLEE IP resources. It converts these requests into the 
5 SLZE call events, sends them to the SLEE CRH (Conversation 
Resource Handler). The SLEE CRH places these call events 
back to the SLEE call event queue. 

The Dispatcher 2010 is registered as a SLEE 
Conversation Resource m order to use the SLEE CRH to 
10 communicate with the SleeEventGateway 2005. The 
SleeEventGateway 2005 sends the Dispatcher the call events 
retrieved from the call event queue. The Dispatcher then 
dispatches the call events to the SDI Physical Network 
resource interface objects. 
-5 An SDI Dialog object is used as a commuting object 

that conveys state and operational instructions between 
resources involved in a transaction. The Dispatcher uses the 
dialog object to communicate with physical network resource 
interface objects, e.g. a DMSU, the SAP, and RIDE. 
20 Depending on the message group and state of a call 

Gvenr, the dispatcher 2010 sends a dialog message to the 
appropriate SDI Physical Network resource interface objects. 

3. 3. 5. 3 New Incoming Calls 

2- The call event retrieved may be of call event message 

group API_CM_EVENT with an Incoming Call event, indicating 
that this is a new incoming call. The Dispatcher 2010 
creates a Dialog object. The Dialog object contains a Dialog 
object ID 1605 ( Trans acti onProtocolI D ) , which uniquely 

30 identifies this call event in the context of the SDI. The 
Transaction Dialog ID 1605 is associated with the SLEE dialog 
ID m the call event, and the association is stored in the 
Dialog Dictionary. The Dispatcher 2010 may, for example, 
create a Dialog object, and send the DMSU a begin ( Dialog ) 

35 message. 
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3. 3. 6 PSTN Elemenrs 

All interfaces to the PSTN are made via one Digital 
Maxn Switch Unit 110. 

5 3. 3. 6. 1 Digital Mam Switching Unit 

Referring to Figure 21, DMSU 2100 encapsulates the 
state of a DMSU switch. A DMSU has a SwitchID 2105 and 
Trunks 2110. A DMSU can be enabled and disabled. The 
Administrator of the network operator provisions the DMSU 

10 2100 with Trunks. A DMSU translates between DMSU Trunks 2110 
and transmission network nodes 500. For an incoming leg, the 
DMSU consults the physical node directory to find the 
physical node 300 associated with the incoming trunk. For an 
outgoing leg, the DMSU 2 100 consults the physical node 

15 directory with the physical node to determine the DMSU trunk. 

3. 3. 7 Announ cements. Speech Applications & Associated 

Devi ces 

An announcement is a message that is available to be 
relayed to a user. Announcements either inform of progress 
and require no response or are prompts for collection of 
information. All announcements that are available are in the 
Announcement Catalog. 

There are two levels of announcement addressing. One 
is the virtual announcement identifier which refers to a 
particular meaning e.g. "Your call cannot be completed at 
this time". The other is address the actual physical 

announcement recording of that meaning in a particular 
language. 

The resource allocator 700 queries the announcement 
catalog with the virtual announcement id and the language to 
determine the resource to play the announcement. The 
announcement catalog contains mappings of virtual 
announcements and language to physical announcements. A 
physical announcement has an identifier and comprises: 

• the host resource identifier, 

• resource command identifier, 



25 
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pag-ng service. A numeric or alphanumeric message can be 
sen*:: to compatible types of radio pagers. 

3. 4 Virtual Network 
5 Referring to Figure 33, a virtual network 800 consists 

of a set of directories which maintain the logical 
associations between users of the network and the 
capabilities which are provisioned for them. Virtual network 
directories provided for this purpose are a Virtual Node 
10 Directory 3300, a Virtual Number Directory 3305, a User 
Directory 3310, and a Service Dictionary 3315. Additionally, 
each Virtual Network 800 has a unique Virtual Network Id 3320 
and a Status 3325 for enabling or disabling the Virtual 
Network 800 as needed. 

15 The Virtual Node Direcrory 3300 provides a collection 

of the Virtual Nodes 310 that are available on the Virtual 
Network 800. The Virtual Number Directory 3305 maintains 
associations between Virtual Network Addresses and Virtual 
Directory Numbers. The User Directory 3310 stores user 

20 profiles which link virtual directory numbers and 
authorisation codes to the services provisioned for a user of 
the network. Services are delivered to a Virtual Network in 
a Service Package. Services are installed and stored in the 
Service Dictionary 3315. 

25 Referring also to Figure 34, the Virtual Network 800 

builds a Profile 3400 for use by the Service Engine 825 in 
delivering a service. A Profile includes a user profile 3405 
and all of its related service profiles 34 10, A Profile is 
obtained from the Virtual Network 800 by use of a 

30 VirtualNetworkAddress , an Authorisation Code, or a Virtual 
Directory Number key. 

3. 4. 1 Profile 

A profile is a commuting object which contains all 
3 5 thac is known about a particular Virtual Network user that 
may be required to process a call. It commutes between a 
virtual network 600 and its associated service engine 
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3, 4. 3. 1 Virtual Dirgctorv Mumbsr 

Referring to Figure 37, a virrual direcrory number 
3700 is a unique represenrar.on of a user on a virtual 
network. A vir-zual directory number has a virtual network 
5 identifier 3705 and a virtual number 5710. The number is a 
TBCD (Telephony Binary Coded Decimal) encoded digit string. 

3. 4. 3. 2 Virrual Network Address 

Referring to Figure 38, a virtual network address 3800 
10 identifies a station on a particular virtual node in a 
particular virtual network 800. 

3, 41 4 User Directory 

Referring to Figure 39, user profiles 3405 detail user 
15 related informarion and the provisionable capabilities for 
each user on a virtual network. User profiles are stored in 
a user directory 3900. User profiles 3405 can be obtained 
from the user directory by use of a virtual directory number 
"3415, an authorisation code, or a user profile id key. A 
20 user profile may be added to the directory 3 900 or one may be 
deleted by adding a null profile with the existing id. 

3. 4. 5 Servi ce Dicti onarv 

Referring to Figure 40, a service is delivered in 
25 ASN. 1 media format as a service package. The service package 
4000 is the definition of a service. A service package 
specifies the features from which an executable service can 
be installed into a virtual nerwork 800. The association 
benween a service package, an installed service, and its 
30 related service profiles is provided by an entry 4010 in the 
service dictionary 4005. 

The service dictionary 4005 stores and maintains these 
service entries 4010. The service dictionary 4005 can locate 
a specified service entry in "he dictionary to retrieve the 
35 service and access its related service profile directory 4015 
to retrieve specified service profile{s). 
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Inteiligenr Nerwork Management Sysrem (INMS) 120 for 
collarion; 

• audit trails to meet the requirements specified by 
the network operator; 
5 • where relevant, conformance to relevant charging 

requirements for exchanges. 

3. 5. 2. 1 Toll Ticket 

Referring to Figure 41, the toll ticket 4 100 is a 
10 commuting object that maintains call statistics. Services 
generate toll tickets 4100 and route them to the billing 
system 220. A toll ticket 4100 contains the following 
inf ormati on: 

• call identity; 

1- • Chargecard number; 

• account number; 

• call start time; 

• call stop time; 

• originating call information; 
2^ • terminating call information. 

The network interconnect maintains a list of active 
dialogs, and matches the Call Identity 4105 with the dialogID 
of an active dialog to obtain r.ore information on the call. 

The toll ticket 4100 is routed by the network 
25 interconnect 8 10 to the software encapsulation of the billing 
system in the management system 820. 



3. 6 Network I nterconnecr 

Referring to Figure 42, the network interconnect 810 
30 contains the connectivity information relating virtual and 
physical nodes. Nodes in the physical network 805 and nodes 
in the virtual network 800 are not aware of each other. 
Therefore, a service running m a virtual network 800 needs 
the network interconnect to find its associated physical 
3 5 node. Likewise, the network interconnect 810 assures that 
dialogs from the physical network 805 arrive at the correct 
virtual network 800. 
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with a particular physical node address. The virtual node 
address indicaiies the virtual network identity. The SDI 
connectivity information maintains the relationships between 
physical nodes 305 and virtual nodes 3 10. It is possible to 
5 associate a maximum of two physical network nodes 305 with 
one virtual network node 310, one being the originating node 
and one being the terminating node. A call is handled by a 
virtual network 800 if and only if all the following are 
asserted: 

• the physical node address is one that is known; • 
the physical node address is associated with a virtual node 
address ; 

• a valid virtual network can be deduced; 

• the virtual network is active; 

15 

■ 3. 6r 4 Physical Node Discrimination 

Services run with knowledge of only the virtual nodes 
^within its particular virtual network 800. Physical network 
discrimination is achieved through the identification of the 

20 physical node address that is associated with a particular 
virtual node address. The physical node address uniquely, 
identifies the physical node. The SDI connectivity 

information maintains the relationships between virtual nodes 
and physical nodes. A call is handled by a virtual network 

25 800 if and only if all the following are asserted: 

• the virtual node address is one that is known; 

• the virtual node address is associated with a 
physical node; 

• the physical node is active. 

30 Figure 24 shows the interactions between the 

components of the SDI 200 in applying the above virtual 
network and physical node discrimination. 

3. 6. 5 Connectivity Pi rectgry 
35 The purpose of Network Interconnect 810 is to maintain 

the connectivity information between the virtual and physical 
networks. The connectivity information is stored in the 
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the application developer's class becomes an embedded object 
inside the persistent wrapper class. Referring to Figure 25, 
the wrapper class is persistent by inheriting from a 
persistent superclass. The wrapper class is a persistent 
class which conraxns the application developer' s original 
class . 

3. 8 Loo 

An SDI 200 may also have a log utility which other 
components can use tie log acrivity and event messages. The 
log utility will preferably interface with thf.^ UNIX file 
system. 



3.9- Process Management Contrnl 

^5 The components of the SDI 200 and services that run 

under its .auspices are all contained within a finite set of 
manageable processes on the target platform. These processes 
can be managed in two ways, i.e. invasively by an operator or 
automatically by heartbeats. In the following, the action 

20 taken by the operator for Process Management Control is 
discussed. Each managed process accepts the following 
stimuli for the purpose of process control; 

• disable (go out of service) 

• enable (come in service) 
25 • reinitialise 

The following are the differenr states the process can 
be m depending on what action (shown above) is performed: 
In Service 
Out Of Service 
Active 
Idle 

Human Busy (hbsy) 
Machine Busy (mbsy) 
I ni tialised/Reinitialise 
35 Figure 26 shows the Process Control State Transition 

Di aaram. 



30 
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STEP 4420: The Service Engine 825 retrieves the 
service from the Virtual Network 800. 

STEP 4425: The Service Engine 825 resolves the 
references in the service. 

5 

4. 2 Virrual Networ>: Provisicnina on the SDI 
Referring to Figure 45, the process for creation and 

deployment of a virtual network 800 on the SDI 200 is as 

follows: 

10 STEP 4500: A Virtual Network 800 is created and 

assigned a VN id. 

STEP 4505: Virtual Network Addresses and Virtual 

Directory Numbers are created and deployed, together with VNA 

and VDN associations. 
15 STEP 4510: User Profiles are created and deployed, 

containing- user data, VDN Service Profile references and any 

necessary "VDN to Service Profile ID" associations. 

4- 3 Physica l Network/Ne tworki nterconnect Provisioning 
20 on the SDT 

Referring to Figure 46, the process for the above is 
as follows: 

STEP 4600: Virtual encapsulations of switches are 
25 provisioned with switch and trunk IDs. 

STEP 4 60 5: Physical Nodes and Virtual Nodes are 
declared and provisioned to the Network Interconnect 810. 
Physical Node - Virtual Node associations are created and 
deployed 

30 

4. 4 Service (Instance) Provisioning on the SDI 
Referring tc Figure 47, the service (instance) 
provisioning process is as follows: 

STEP 4700: A Service Profile is created and deployed 
35 to a Virtual Network 800 in the SDI 200. 

STEP 4705: A User Profile is updated with a VDN and 
a Service Profile reference and deployed. 
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A profile can be viewed as the specification of a set 
of attributes describing how a particular service instance is 
to be tailored. Profiles can be global across all networks 
800, for instance network operator d.efined profiles, network 
5 wide to a particular virtual network 800, or specific to a 
particular user. Where conflict arises, the priority of 
profiles will be first the network operator, then the 
customer (for instance where the customer is an entity 
responsible for bills on behalf of multiple users) and 
10 finally the single user. 

A profile contains: 

1. the virtual network DN, 

2. user attributes, these being default declarations 
of call state that are established when a caller initiates a 

15 call and would include things such as default call type 
(speech, 1, IkHz, data), 

2. authorisation code, 

4. rule list, 

5. feature lists (originating and terminating). 

20 Looking at the last of the above, every profile has 

lists of features that are available. Features are 

classified as originating features (for example outgoing 
calls barred, originating screening, network side updates, 
restricted access etc) or terminating features (for example 

25 incoming calls barred, terminating screen, call forward, 
divert on busy etc). Every profile has two feature lists, 
one of originating and one of terminating features. A 
feature list contains, for every feature, the feature name, 
feature view and feature instance reference. The feature 

30 instance reference points to the provisioned persistent 
feature object instance for this profile. The feature list 
may in practice be empty. 

Feature views are the representation of a call state 
that fulfils the conditions for that feature to be invoked. 

35 The view that a feature requires is specified by the feature 
provider in the feature package. The view for a feature is 
specified in terms of the presence or absence of an element 
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BLACKBOARD TECHI-TIOUE IN PRO^TIDING SERVTCES 
In the SDI 200, a blackboard is a software object that 
maintains a picture of a call srate. The picture changes as 
a call is progressed by the addition, subtraction and 
5 modification of scenes by other objects posting to the 
blackboard. 

Blackboard systems are known, for instance in a 
military context where, for example, a fighter pilot has to 
process incoming data in order to select from a range of 
10 actions. The model is a knowledge-based system monitoring 
the input and advising the pilor when something interesting 
occurs; e.g. when a real target or threat is identified among 
many dummy target or threats. The financial trader is in a 
similar pos-ition, being the recipient of vast quantities of 

15 data from several information feeds, all of them in need of 
analysis _to determine (a) if anything interesting has 
occurred requiring further analysis, and (b) what the 
appropriate action should be. 

A blackboard system is so called because it imitates 

20 a group of highly specialised experts sitting around a 
blackboard in order to solve a problem. As new information 
arrives it is written up on zhe blackboard where all the 
experts can look. When an expert sees that s /he can 
contribute a new fact based on specialist knowledge, s /he 

25 raises a hand. This might be to confirm or refute an 
hypothesis already on the board or to add a new one. The new 
evidence will now be available ro the other experts who may 
in turn be prompted to contribure to the discussion. The 
chairman of the group monitors rhe experts and selects their 

30 contributions in order, according to an agenda visible on the 
board. Common storage is the blackboard, and the agenda is 
under the control of a specialised inference program. 

If the components of a blackboard system need to 
communicate, there are essentially rwo methods of achieving 

55 this. Obj ec-c-orienred systems allow objects to send and 
receive messages which have definite destination objects when 
sent. In blackboard systems zr.e messages are posted to a 
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the contrcl of the SDI 200 and the invocation of feature 
rules, until a quiescent state, resulting in a terminating 
DN, is reached. Translation from the logical world back to 
physical representations occurs when the feature requires 
5 further network interaction or the call is complete and 
requires a terminating leg. 

If it is not possible to identify a user from the 
physical identifiers provided by the virtual network 800, the 
SDI 200 will prompt for an authorisation code. This will be 
10 used to allocate an originating DN so that a profile may be 
retrieved and feature processing may proceed. 

A simplified representation of the retrieval of a 
profile from a service network DN, in this case an 
originating DN, is shown in Figure 27. The feature 2700 
15 registers a view with the blackboard 2705. If there are 
sufficient elements of data present, that is there is a new 
phone number together with the state of ' no reply for the 
feature 'Call forward on no reply' , then the feature will be 
triggered by the view. Consequently, it will process the 
20 view plus any additional parameters and post back resulting 
scenes to the blackboard 2705. Other features viewing the 
blackboard may then, when invited to focus on their view of 
the call picture, be triggered by the scenes posted as a 
result of another feature processing its view. 
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CLAIMS 

1. A service delivery system, for making services available over a 
communications network, where one or more sen/ices selected from a group of 
5 sen/ices is made available to at least one network user, wherein said service delivery 
system comprises service provision functionality dedicated to said at least one user, 
the functionality so dedicated comprising a service directory defining the one or more 
selected services available to that user, and a number directory defining a virtual 
network dedicated to that user out of said communications network, within which the 
10 services of the service directory are available to that user. 

2. A service delivery system according to claim 1 wherein the service delivery 
system is provided with a stored array of sen/ice independent features, and means for 
accessing the service independent features to support provision of a service for one 

15 of said service directories, over a virtual network within which the service is available, 
in response to a call instance relevant to the virtual network. 

3. A service delivery system, for delivering services to users of a 
communications network, one or more services preselected from a group of services 

20 being available to each user, or set of users, wherein the sen/ice delivery system is 
provided with the following data structures: 

i) a library of service independent features for use in providing a service 
over the communications network; 

ii) a set of node identifiers for nodes of the communications network; 

25 iii) an array of virtual networks, each virtual network being allocated to a 

user or set of users, and each virtual network being defined in the array by a set of 
virtual node identifiers together with an indication of the service or services allocated 
to its user or set of users; and 

iv) mapping between the node identifiers for nodes of the communications 

30 network and the virtual node identifiers; and wherein the service delivery system is 
further provided with a service execution means which acts on user requests for 
sen/ices which can be satisfied within a virtual network to provide execution of the 
relevant services. 
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1 0. A service delivery system according to any one of the preceding claims which 
presents a common programming interface to elements of the communications 
network in providing, modifying, enhancing or adding a sen/ice. 
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B) communicating with the representation of the identified virtual network to 
identify a user profile associated with that virtual node identifier, 

C) communicating with the identified user profile to verify that the requested 
5 service is available, to identify the relevant service package and to obtain any user- 
specific parameters for that service, 

D) communicating with the service package store to identify the relevant 
selected set of units of executable code together with its predefined order, and 

10 

E) communicating with the feature data store to obtain the selected set of 
units of executable code to be executed to provide the requested service. 

12. A system according to Claim 11 wherein there is provided a service engine 
15 which is common to a plurality of, or all of, the virtual network representations. 

13. Asystem according to either one of Claims 1 1 or 1 2 wherein the service 
engine additionally executes the selected set of units of executable code, applying 
the user-specific parameters, such that the selected service is provided. 

20 

14. A system according to any one of Claims 11, 12 or 13 wherein there are 
provided a plurality of service package stores, each being comprised by a virtual 
network representation. 

25 15. A system according to any one of Claims 1 1, 12, 13 or 14 wherein each 
virtual network representation is structured as data encapsulated in process 
software to provide an object. 
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Fig. 13. 
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